The present invention relates to computing systems access and, more specifically, to specifying access control policies of information for various applications and a computing system.
XACML stands for eXtensible Access Control Markup Language. In general, it is a declarative access control policy language implemented in XML and a processing model, describing how to interpret the policies. XACML is widely accepted as a de facto standard for specifying access control policies in computing systems. For example, XACML has become the de facto standard for specifying access control policies for various applications, especially web services. It defines both a policy language and an access control decision request/response language, both given in XML (eXtensible Markup Language). Authorizations are given as rules that express permissions and prohibitions. Rules are combined into policies and policies may be grouped to policy sets. Different combining algorithms allow the reconciliation of the results into one final access decision.
Due to its hierarchical structure XACML lends itself very well to the concise definition of sophisticated, possibly federated authorization policies. Due to the increasing complexity of access control policies used in practice, automated methods for analyzing these policies must be provided. These methods include change impact analysis, entitlement analysis, access report generation and assurance of Separation of Duty constraints. Despite language's advantages for specifying access control policies, XACML-based access control systems perform inefficiently and do not scale well when the policy base becomes larger and more complex.
The inefficiencies are largely due to the fact that for every single access request the entire hierarchy must be traversed in order to find and evaluate the matching authorization policy elements that contribute to this particular access decision. This process often involves a large number of mainly string-based comparisons. FIG. 1 shows the basic XACML hierarchy 100. The hierarchy 100 includes a policy set 102. As shown, the hierarchy contains only one policy set 102. Of course, the hierarchy 100 could include several policy sets 102. Indeed, the policy set 102 may include other policy sets within it. In general, a policy set, as the term is used herein, shall refer to a container that can hold other policies or policy sets as well as references to policies found in remote locations. Each policy set includes one or more policies 104. A policy, as the term is used herein, represents a single access control policy, expressed through a set of rules 106. Each rule 106, based on the input, produces a binary decision. For example, permit or deny.
A policy or policy set may, thus, contain multiple policies or rules, each of which may evaluate to different access control decisions. Therefore, XACML has a collection of Combining Algorithms to reconcile the decisions made by these rules. Each algorithm represents a different way of combining multiple decisions into a single result. There are Policy Combining Algorithms (used by policy set) and Rule Combining Algorithms (used by policy). An example of these is the Deny Overrides algorithm, which says that no matter what, if any evaluation returns Deny, or no evaluation permits, then the final result is also Deny. Thus, this combiner can be regarded as a logical conjunction of permits. At present, there are seven Combining Algorithms to build up increasingly complex policies supported by XACML.
A target 108 is a set of simplified conditions for a desired resource for a particular subject and a related action. These conditions use boolean functions to compare values found in a request with those included in the target. If all the conditions of a Target are satisfied, then its associated policy set 102, policy 104, or rule 106 applies to the request.
Once a policy 104 has been found and verified to apply to a given request, its rules 106 are evaluated. Rules have an effect 112 represented as a Permit or Deny that is associated with successful evaluation of the rule. Rules may also have a condition 110. If this condition 110 evaluates to true then the rules effect 112 is returned. Evaluation of a condition 110 may also result in an error (Indeterminate) or discovery that the condition 110 does not apply to the request (NotApplicable). Conditions can be quite complex, built from an arbitrary nesting of functions and attributes. Attributes are named values of known types that may include an issuer identifier or an issue date and time. Specifically, attributes are characteristics of the Subject, Resource, Action, or Environment in which the access request is made. A user's name, its security clearance, the file the user want to access, and the time of day are all attribute values. When a request is sent from a Policy Enforcement Point (PEP) to a Policy Decision Point (PDP), that request is formed almost exclusively of attributes, and their actual values will be compared to attribute values in a policy to make the access decisions.
In summary, authorizations are expressed in XACML by access rules that specify the subject, resource and action elements of an authorization. These elements may define the applicable subjects, resources, and actions specifically, or may be wildcard elements, which match all specific elements in the corresponding category. For example, a rule expressing authorization of a user “Alice” to perform the action “read” on a data object “Manuals” can be defined by (using some simplifications in the XML syntax):
<Rule Effect =“ Permit ”>  <Target >    <Subject “ Alice ”>    <Resource “ Manuals ”>    <Action “ read ”>  </ Target ></ Rule >
Groups of rules can be combined via combining algorithms that implement logical operations into policies, and groups of policies can be similarly combined into policy sets. Thus, the overall access control policy data structure in XACML typically comprises multiple policy sets, each specifying the combining algorithms to be applied by the decision logic to policies, and, within those policies, rules, which apply to particular combinations of subject/resource/action elements.
In operation, the decision logic compares the subject/resource/action triple in an access query to the targets in the data structure to identify the applicable policy sets, policies and rules, and then evaluates these accordingly. This evaluation yields a permit or a deny decision in response to the access request. The disadvantage of this representation is that for each request the complete XACML hierarchy must be processed in order to find the matching policy sets, polices and rules, to evaluate them and to compute the access decision result. For real-world authorization policies comprising thousands of users and millions of resources this is a time and memory consuming process.
The hierarchical nature of XACML also creates problems when analyzing authorization policies. In contrast to policy evaluation, it is not sufficient to decide that a particular subject may or may not access a particular resource but to reason why this is the case. For this reason even basic optimization strategies such as disregarding non-applicable portions of the policy cannot be deployed.